Many applications and libraries are distributed in an intermediate format, such as MICROSOFT™ Intermediate Language (MSIL). These intermediate language binaries (also known as managed assemblies in the case of MICROSOFT™ .NET) are typically compiled dynamically at runtime in a virtual machine environment using a Just-in-Time (JIT) compiler. An alternative to dynamic compilation is pre-compilation via Native Generation (NGen). NGen generates machine code and runtime data structures from the intermediate language and persists them in files on disk. The images produced by NGen are called Native or NGen images. Unlike JIT-compiled code, code and data structures in NGen images can be shared across processes. For libraries and frameworks that are typically shared across multiple processes, NGen is extremely useful since it minimizes the working set of each managed process. NGen therefore reduces the overall memory utilization of the system. NGen is also very useful for minimizing start up time of client-side applications.
Several managed platforms/applications are using NGen. Unfortunately, however, it is quite difficult to use NGen in these current platforms. Since NGen images are created on the end-user machine, NGen commands are typically chained through the framework/application's installer. Typically, that involves writing a custom action (such as a MICROSOFT™ WINDOWS™ Installer action) that invokes a command-line tool (ngen.exe in the case of MICROSOFT™ .NET). Custom actions are not trivial to write. Moreover, NGen images may become invalidated for a variety of reasons (such as when the corresponding libraries/assemblies are serviced/updated), and need to be regenerated each time that happens by issuing explicit commands through the command line tool.
Contemporary browsers and other applications allow plug-ins, which in general comprise hosted software code that interacts with the hosting browser/application to provide additional functionality. One reason for using plug-ins is to increase security; the hosting browser limits the actions that the hosted code (which is generally untrusted) can perform. The Internet has become very dangerous, with malicious websites often attempting to cause a user to download and run harmful code that may damage the user's computer system or destroy the user's data. Thus, web browsers often include restrictions on the code that can run, and the plug-ins that can perform actions on the user's computer system. Plug-ins increase the size of the sandbox provided by the browser, because they allow more functionality on the web while decreasing the number of untrusted applications installed. One such plug-in is MICROSOFT™ SILVERLIGHT™, which provides a platform that allows application developers to create rich web applications hosted in the browser that typically include animation, vector graphics, and/or media (e.g., audio/video) content playback. Another example plug-in is ADOBE™ FLASH™.
Virtual execution environments typically make it possible for a host application (the host itself may be written in native or managed code) to customize various aspects of the environment in which the hosted managed code runs. For example, the host can specify settings related to security (to set up a sandbox), and loading dynamically linked libraries (DLLs) (e.g., to indicate where to load DLLs from). Ahead-of-time compilers like NGen typically do not have access to these settings since they are generated as part of running the host application. For example, these settings are not typically known at install time. Current solutions expect a developer to run the host application, record the settings, and then make that information available to the compiler. Often times, there is no supported way to provide this information, and even when there is, the process is manual and tedious. As a result, hosted managed code is typically not pre-compiled, causing performance and resource usage to suffer.